Всех уволю к чертям собачьим!

Вчера наткнулся на занимательный пост (читать только психически стабильным), в котором некто Денис Теплов (директор по продукту в Лиге Ставок) похвастался, что уволил сотрудника, когда узнал, что у него есть вторая работа, попутно назвав эту компанию «куколдами» и предложил сделать «реестр пидорасов», куда бы попадали все, кто работает в IT на нескольких работах сразу.

Хочу объяснить своим подписчикам, ведь среди вас есть те, кто планирует расти в руководящие позиции, почему главный «куколд» в этой истории — автор поста.

Специфика IT такова, что у разработчика существует условный КПД. Возьмём за эталон 100%. Это тот случай, когда разработчик пишет безошибочно код и не отвлекается на ютубчик и чатики ровно 8 часов в день. Надеюсь, всем понятно, что это утопия. В реальности ожидаемый КПД разработчика — 60%.

Это будет отличный результат для компании.

Но процессы и планирование, особенно в хороших компаниях, учитывают ещё и то, что от 60% отнимается ещё около 40% на организационные моменты: встречи, обсуждения, раскопки в коде и другие активности, не направленные на движение продукта вперёд.

Итого мы получаем цифру продуктивности в 40% от «утопического КПД». Путем нехитрых манипуляций, мы с вами узнали, что из 8 часов среднестатистический разработчик двигает компанию вперёд +- 3,5 часа.

Видите, к чему я веду? Правильно. Если у разработчика две работы, где есть прозрачные процессы, то у него получается 3,5 ч. + 3,5 ч. продуктивной и спокойной работы разработчика. Ровно из-за того, что такие расчёты применимы в большинстве компаний, практически всё IT или работает на двух работах, или основа + какой-то фриланс. Если кто-то не работает на двух работах в текущий момент времени, значит, он работал, но устал. Так как всё-таки ему нужно работать вдвое больше, чем его «базовый КПД».

Давайте попробуем понять логику Дениса. Он НЕ ставит тезис, что задачи разработчик начинает выполнять долго и с низким качеством, что побудило его инициировать увольнение. Единственный пункт, который там есть — две работы у сотрудника.

Какие основные задачи и KPI у бизнеса? Верно. Развитие и стабильность продукта плюс соблюдение сроков и квартальных планов.

Если у тебя всё работает как часы, тебе важно, сколько работ у твоих сотрудников? Адекватному руководителю/директору — нет.

Если у тебя в компании ставят заранее завышенные требования к развитию продукта (не учитывая ни capacity команд, ни рост бизнес-отдела, не закладывает форс-мажоры), то тут, извините, вопросы не к сотрудникам. Когда компания вместо ожидаемых 40% КПД требует от сотрудников 80%, то она заранее соглашается на то, что сотрудники начнут выгорать, уставать, класть болт, и на дистанции это неминуемо приведёт к провалу всех сроков и/или снижению качества продукта и текучке в компании. В итоге все разговоры с Денисом свелись к тому тезису:"Качество страдает!! И вообще у него офф.договор с нами!11!!1! пыщ-пыщ-пыщ (слюна полетела во все стороны)". Но в процессе лёгкого обсуждения выяснилось, что они и так и так уволили бы сотрудника, ведь к его качеству и скорости были вопросы. Причина тут абсолютно не важна. Будь то вторая работа, просто усталость, потеря вовлеченности или любая другая альтернативная причина — работник перестал справляться с обязанностями. Компания с ним прощается.

Не будьте как Денис.

Путь к СЕО (18+). Подписаться

Другие соц.сети:
📷 Instagram

Interview System Design

Сегодня у нас в гостях вновь наш старый друг Александр Сычёв, и мой коллега по работе Влад Бац. Ребята провели мок-интервью, mobile system design. Совместно спроектировали фичу мобильного приложения. Участники определили требования к фиче приложения.
Разработали архитектуру, обсудили различные альтернативные подходы и оценили масштабируемость и надежность проектируемой системы.

Для тех, у кого плохо работает ютуб, мы добавили выпуск в ВК видео, рутуб и на наш бусти.

Смотрите данный выпуск, будет очень интересно!

💬Т-Г канал Саши @headOfMobile
😎 Школа разработчиков KTS @metaclass

📨 Apple оштрафовали на $3 млн в Бразилии за сбор данных приложением FaceApp.

Кольцо прогресса в SwiftUI

Это краткое руководство для создания пользовательского индикатора прогресса в приложениях на SwiftUI

🔜 Используются переменные состояния, такие как @State var degrees: Double и @State var progress: CGFloat, для управления анимацией и отображением прогресса.

🔜 Кольцо создается с использованием Circle() и методов stroke для настройки толщины и цвета.

🔜 Добавляется градиент с помощью LinearGradient, чтобы визуально улучшить кольцо прогресса.

🔜Реализуются анимации, делающие индикатор более плавным и динамичным.